home *** CD-ROM | disk | FTP | other *** search
/ C/C++ Interactive Reference Guide / C-C++ Interactive Reference Guide.iso / c_ref / csource3 / 137_01 / sep83col.ddj < prev    next >
Encoding:
Text File  |  1979-12-31  |  10.4 KB  |  208 lines
  1. .pl 60
  2. ..
  3. .. DDJ Column #1        as of 19-Jun-83
  4. .. (C) 1983 Anthony Skjellum. 
  5. .. For publication in DDJ
  6. ..
  7. .. file (DDJCOL.1)        created:  19-Jun-83
  8. ..                updated:  21-Jun-83
  9. ..                updated:  23-Jul-83
  10. ..
  11. ..                completed: 24-Jul-83
  12. ..
  13. .he   C/Unix  Column by Anthony Skjellum. (C) 1983.  For October 1983 DDJ.   
  14.  
  15.  
  16.     This column will deal with the C programming language and the  UNIX 
  17. operating  system.   These  two software systems help  programmers  produce 
  18. maintainable  and  portable code.   While C is widely supported  on  micro-
  19. computers,  and clearly merits discussion, UNIX is only beginning to become 
  20. available,  and then only on more expensive microcomputers.   Nevertheless, 
  21. UNIX  design concepts are filtering down into the more conventional operat-
  22. ing  systems.   This makes discussing UNIX features,  successes and  short-
  23. comings both interesting and worthwhile.  
  24.  
  25.     This  column  will  also  include  discussion  of  software  design 
  26. approaches  and  current trends.   Specific features of C and UNIX will  be 
  27. discussed  and  more general programming concepts will also  be  presented.  
  28. This  will  make  some of the material salient to many  types  of  computer 
  29. systems and languages.
  30.  
  31.     Readers will be invited to participate in this column.  I hope that 
  32. some of the topics will spark readers into producing responses,  new ideas, 
  33. and even some new code.  Since this column will be bi-monthly, readers will 
  34. have plenty of time to respond to the topics covered in any given issue.
  35.  
  36.     We  start  this first column with a discussion of the layout  of  C 
  37. code.   The  second topic is a discussion of runtime libraries and  linkage 
  38. compatibility  for  several 8080/Z80/8086 compilers.
  39.  
  40.     In  the  next  column,  we  will begin  to  discuss  how  Unix-type 
  41. environments tend to produce non-interactive programs.   I look forward  to 
  42. your responses and suggestions for future topics.
  43.  
  44.  
  45.                             I. Layout of C Code
  46.  
  47.     The C language is one of the few standards which prevails between a 
  48. wide  variety of computers.   The C Programming Language,  by Kernigham and 
  49. Ritchie, defines a standard language and runtime library and also discusses 
  50. implementation differences in several mini-computer  implementations.   The 
  51. book  does not define a standard for the layout and presentation of C code, 
  52. but  leaves  this as a matter of personal taste.   After  reading  a  large 
  53. number  of  C programs from many sources,  I have reached the opinion  that 
  54. programmers pay too little attention to this aspect of C  programming.   In 
  55. the following,  I will explain the problem as I see it,  suggest a standard 
  56. for C code layout, and propose a possible solution.
  57.  
  58.     Whenever I receive a new piece of C code, I always check to see how 
  59. the  programmer  has presented the code.   A clear presentation  with  many 
  60. comments  and   an uncluttered look is important for maintaining such  code 
  61. and  for  the benefit of another programmer who must understand  the  code.  
  62. More often than not, the code looks something like the following:
  63.  
  64.     main(){printf("Hello world\n");
  65.     }
  66.  
  67. The  point  is that the programmer hasn't formatted his  program  properly. 
  68. This  makes  it  difficult to follow the inherent block  structure  of  the 
  69. language.   The cluttered look that results from improper  indentation,  is 
  70. often also accompanied by a paucity of comments.   The result is code which 
  71. is hard to understand, improve or debug.
  72.  
  73.     The style presented in Kernigham and Ritchie is consistent, but not 
  74. optimal  since it does not present blocks and block nesting in the clearest 
  75. way possible.  For example, an if...else loop would look as follows:
  76.  
  77.         if ((fp = fopen(argv[1],"r")) == NULL) { /* not found */
  78.               fprintf(stderr,"%s not found\n",argv[1]);
  79.               exit(1);
  80.         } else {         /* the file is present */
  81.               fprintf(stderr,"%s is on-line\n",argv[1]);
  82.               fclose(fp);
  83.         }
  84.         
  85. My preference is for the following format for the above fragment:
  86.  
  87.         if((fp = fopen(argv[1],"r")) == NULL)  /* not found */
  88.         {
  89.             fprintf(stderr,"%s not found\n",argv[1]);
  90.             exit(1);  /* exit with error status 1 */
  91.         }
  92.         else    /* the file is present */
  93.         {
  94.             fprintf(stderr,"%s is on-line\n",argv[1]);
  95.             fclose(fp); /* close the file */
  96.         }
  97.  
  98. In  the second form,  eight-space (standard) tabs are used for  indentation 
  99. (as  opposed  to the six-space indentation used by the book.)   Braces  are 
  100. almost  always on their own lines and the lowest level braces appear at the 
  101. left  margin.   Braces indicate the nesting level of the  expression  which 
  102. invoked  them,  and  their contents are themselves indented  an  additional 
  103. level.   Only  one  statement is placed on a line,  and comments are  added 
  104. liberally  to  make the code more readable.  Finally,  the  space  used  by 
  105. Kernigham  and Ritchie between keywords and their parenthetical expressions 
  106. is omitted.  
  107.  
  108.     The  above  example  illustrates the layout  standard  which  I  am 
  109. proposing.   The  standard  is  summarized  in Table  I.   The  purpose  of 
  110. proposing this standard is to induce C programmers to think more  carefully 
  111. about  the  layout  and presentation of their C  code.   I  welcome  reader 
  112. reaction to this layout proposal.
  113.  
  114.     Clearly,  there is more to programming than just the layout of  the 
  115. code.   The  data  structures used,  and program structure are  crucial  in 
  116. producing a good piece of software.  However, without good layout, the best 
  117. program may be very difficult to understand, maintain, or improve.
  118.  
  119.                             A Possible Solution
  120.  
  121.     I expect that even if there were a layout standard described in The 
  122. C Programming Language, some programmers would deviate from this.  In order 
  123. to  provide  programmers  with  the  code  layouts  which  they  prefer,  C 
  124. beautifiers are created.  Such programs take C code as input and add/remove 
  125. white  space  characters  in order to reformat the C code  to  some  layout 
  126. specification.   This  allows  each  programmer  to distribute  code  in  a 
  127. standard layout,  while using the layout he prefers for local copies of the 
  128. code.  
  129.  
  130.     Beautifiers  already  exist.   For  example,  Berkeley UNIX  has  a 
  131. beautifier  called  CB.   This  program is fairly  simple-minded  but  will 
  132. convert  totally  unformatted C code (ie one using the  minimum  amount  of 
  133. white  space) into the Kernigham and Ritchie-type layout.   More  ambitious 
  134. beautifiers  can  be  created,  and this is left for readers  to  work  on.  
  135. Readers  who create their own beautifiers are invited to submit their  code 
  136. for publication in this column.
  137.  
  138.     We  now turn to our second topic of this column:  runtime libraries 
  139. and linkage compatibility in C compilers.
  140.  
  141.                            II. Runtime Libraries
  142.  
  143.     The  C Programming Language defines a standard runtime library  for 
  144. C.   Some of the features provided are only feasible under Unix.  Thus, for 
  145. CP/M, CP/M-86, and MS-DOS implementations, only part of the runtime library 
  146. can be supported.  Yet, some C compilers do not provide a compatible subset 
  147. library.   The  result  is  code which cannot be  easily  transported  from 
  148. compiler to compiler,  or machine to machine.   Thus, such compilers negate 
  149. one of the primary purposes of the C programming language: portability.
  150.  
  151.     The  BDS C Compiler is one such software product.   It is an excel-
  152. lent  subset  compiler,  but its runtime library is incompatible  with  the 
  153. standard.   After using BDS C for more than three years, I have accumulated 
  154. a  significant  collection  of  useful  subroutines  and   programs.    Un-
  155. fortunately,  some  of  this software depends heavily on the BDS C  runtime 
  156. library.   This  code will require significant work before it can  be  used 
  157. with another compiler.  So be aware of this pitfall and be prepared to live 
  158. with the consequences if you choose a compiler with a non-standard  runtime 
  159. library.
  160.  
  161.     BDS  C  is  not  the only compiler whose runtime  library  is  non-
  162. standard.   The Whitesmith C compilers use their own too.   However,  since 
  163. Whitesmith  compilers  are  available  for  many  different   environments, 
  164. portability  between Whitesmith compilers is immediate.   Nevertheless,  my 
  165. preference  is for code written for use with the standard library  and  for 
  166. compilers which support that library in full or subset form.
  167.  
  168.  
  169.                                Link Formats
  170.  
  171.     Besides  incompatible runtime libraries,  there is the question  of 
  172. subroutine linkage,  and linkage editor formats.   Once again BDS C is non-
  173. standard.   That  is,  it uses its own linker instead of conforming to  the 
  174. Microsoft  .REL format.   (Some 8080/Z80 compilers do support the  standard 
  175. such as the Q/C compiler from the Code Works).  Compatibility with the .REL 
  176. format  is a considerable blessing,  if you plan to link other software  to 
  177. your C programs.
  178.  
  179.     The  lack  of linkage compatibility is not limited to  the  CP/M-80 
  180. world.   A wide variety of C compilers sold for MS-DOS and CP/M-86 fail  to 
  181. use the appropriate standard.   Most notably,  Computer Innovations' excel-
  182. lent  C86 compiler uses its own internal format.   This makes it impossible 
  183. to use C86 to produce subroutines for other compiled languages under MS-DOS 
  184. or CP/M-86.   Fortunately,  the MANX AZTEC compilers can be used to produce 
  185. Microsoft format object code, as an option.
  186.  
  187.     The  reasons  for the incompatibility are probably  manifold.   The 
  188. usual  response from the companies producing the incompatible  products  is 
  189. that they prefer their own format to Microsoft's.   Why is this?  I suppose 
  190. this results from programmers who don't care about standards or just didn't 
  191. consider  that  their  end  users would find a  compatible  linkage  format 
  192. useful.   In  any  case,  be  aware  of the linkage format used  by  the  C 
  193. compilers you select.
  194.  
  195.                                 Conclusion
  196.  
  197.     In  this  column,  we  have discussed a problem in C  code  layout, 
  198. defined  a potential layout standard and also discussed incompatibility  in 
  199. C object code formats and runtime libraries.  
  200.  
  201.     Perhaps  some  interested readers will produce a C  beautifier  for 
  202. inclusion  in  this  column.    We  look  forward  to  your  responses  and 
  203. suggestions.
  204.  
  205.     Next time,  we'll begin discussing how Unix-type environments  tend 
  206. to produce non-interactive code.
  207.  
  208.